1
2
Næste
Ingen.
JSON er kun data, og hvis du inkluderer en kommentar, vil det også være data.
Du kan have et udpeget dataelement kaldet "_comment" (eller noget), der skal ignoreres af apps, der bruger JSON-data.
Du ville sandsynligvis være bedre med kommentaren i de processer, der genererer / modtager JSON, da de formodes at vide, hvad JSON-dataene vil være på forhånd, eller i det mindste strukturen af dem.
Men hvis du besluttede at:
{
"_comment": "kommentarteksten kommer her ...",
"ordliste": {
"title": "eksempel på ordliste",
"GlossDiv": {
"title": "S",
"GlossList": {
"GlossEntry": {
"ID": "SGML",
"SortAs": "SGML",
"GlossTerm": "Standard Generalized Markup Language",
"Akronym": "SGML",
"Forkortelse": "ISO 8879: 1986",
"GlossDef": {
"para": "Et meta-markup-sprog, der bruges til at oprette markup-sprog såsom DocBook.",
"GlossSeeAlso": ["GML", "XML"]
},
"GlossSee": "markup"
}
}
}
}
}
|
Nej, kommentarer til formularen // ... eller / * ... * / er ikke tilladt i JSON. Dette svar er baseret på:
https://www.json.org
RFC 4627:
Applikationen / json Media Type for JavaScript Object Notation (JSON)
RFC 8259 JavaScript Object Notation (JSON) Data Interchange Format (super Mercedes RFCs 4627, 7158, 7159)
|
Medtag kommentarer, hvis du vælger; fjern dem med en minifier inden parsing eller transmission.
Jeg har lige frigivet JSON.minify (), der fjerner kommentarer og mellemrum fra en blok af JSON og gør det til gyldigt JSON, der kan parses. Så du kan bruge det som:
JSON.parse (JSON.minify (my_str));
Da jeg frigav det, fik jeg et enormt tilbageslag af folk, der ikke var enige med selv tanken om det, så jeg besluttede at skrive et omfattende blogindlæg om, hvorfor kommentarer giver mening i JSON. Det inkluderer denne bemærkelsesværdige kommentar fra skaberen af JSON:
Antag at du bruger JSON til at beholde konfigurationsfiler, som du gerne vil kommentere. Gå videre og indsæt alle de kommentarer, du kan lide. Rør det derefter gennem JSMin, inden du afleverer det til din JSON-parser. - Douglas Crockford, 2012
Forhåbentlig er det nyttigt for dem, der er uenige i, hvorfor JSON.minify () kan være nyttigt.
|
Kommentarer blev fjernet fra JSON ved design.
Jeg fjernede kommentarer fra JSON, fordi jeg så, at folk brugte dem til at holde analysedirektiver, en praksis, der ville have ødelagt interoperabilitet. Jeg ved, at manglen på kommentarer gør nogle mennesker triste, men det burde det ikke.
Antag at du bruger JSON til at beholde konfigurationsfiler, som du gerne vil kommentere. Gå videre og indsæt alle de kommentarer, du kan lide. Rør det derefter gennem JSMin, inden du afleverer det til din JSON-parser.
Kilde: Offentlig erklæring af Douglas Crockford om G +
|
JSON understøtter ikke kommentarer. Det var heller ikke beregnet til at blive brugt til konfigurationsfiler, hvor kommentarer ville være nødvendige.
Hjson er et konfigurationsfilformat for mennesker. Afslappet syntaks, færre fejl, flere kommentarer.
Se hjson.github.io for JavaScript, Java, Python, PHP, Rust, Go, Ruby, C ++ og C # biblioteker.
|
ANSVARSFRASKRIVELSE: DIN GARANTI er ugyldig
Som det er blevet påpeget, udnytter dette hack implementeringen af spec. Ikke alle JSON-parsere forstår denne type JSON. Især streaming af parsere kvæles.
Det er en interessant nysgerrighed, men du bør virkelig ikke bruge det til noget som helst. Nedenfor er det originale svar.
Jeg har fundet et lille hack, der giver dig mulighed for at placere kommentarer i en JSON-fil, der ikke påvirker parsing eller ændrer de data, der repræsenteres på nogen måde.
Det ser ud til, at når man erklærer et objekt bogstaveligt, kan man angive to værdier med den samme nøgle, og den sidste har forrang. Tro det eller ej, det viser sig, at JSON-parsere fungerer på samme måde. Så vi kan bruge dette til at oprette kommentarer i kilden JSON, der ikke vil være til stede i en parset objektrepræsentation.
({a: 1, a: 2});
// => Objekt {a: 2}
Object.keys (JSON.parse ('{"a": 1, "a": 2}')) længde;
// => 1
Hvis vi anvender denne teknik, kan din kommenterede JSON-fil muligvis se sådan ud:
{
"api_host": "Værtsnavnet på din API-server. Du kan også angive porten.",
"api_host": "hodorhodor.com",
"retry_interval": "Intervallet i sekunder mellem forsøg på mislykkede API-opkald",
"forsøg_interval": 10,
"auth_token": "Godkendelsestokenet. Det er tilgængeligt i dit udviklerdashboard under 'Indstillinger'",
"auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
"favorite_numbers": "En matrix, der indeholder mine favoritnumre hele tiden",
"favorit_numre": [19, 13, 53]
}
Ovenstående kode er gyldig JSON. Hvis du analyserer det, får du et objekt som dette:
{
"api_host": "hodorhodor.com",
"forsøg_interval": 10,
"auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
"favoritnummer": [19,13,53]
}
Hvilket betyder, at der ikke er noget spor af kommentarerne, og de vil ikke have underlige bivirkninger.
Glad hacking!
|
Overvej at bruge YAML. Det er næsten et supersæt af JSON (stort set al gyldig JSON er gyldig YAML), og det tillader kommentarer.
|
Du kan ikke. I det mindste er det min erfaring fra et hurtigt blik på json.org.
JSON har sin syntaksvisualiseret på den side. Der er ingen bemærkning om kommentarer.
|
Kommentarer er ikke en officiel standard, selvom nogle parsere understøtter C ++ - stil kommentarer. En, som jeg bruger, er JsonCpp. I eksemplerne er der denne:
// Konfigurationsmuligheder
{
// Standardkodning til tekst
"kodning": "UTF-8",
// Plug-ins indlæst ved opstart
"plug-ins": [
"python",
"c ++",
"rubin"
],
// Indrykningsstørrelse på fanen
"indent": {"længde": 3, "use_space": sandt}
}
jsonlint validerer ikke dette. Så kommentarer er en parserspecifik udvidelse og ikke standard.
En anden parser er JSON5.
Et alternativ til JSON TOML.
Et yderligere alternativ er jsonc.
Den nyeste version af nlohmann / json har valgfri understøttelse til ignorering af kommentarer til parsing.
|
Du skal skrive et JSON-skema i stedet. JSON-skema er i øjeblikket en foreslået specifikation til internetudkast. Udover dokumentation kan skemaet også bruges til validering af dine JSON-data.
Eksempel:
{
"beskrivelse": "En person",
"type": "objekt",
"ejendomme":
{
"navn":
{
"type": "streng"
},
"alder":
{
"type": "heltal",
"maksimum": 125
}
}
}
Du kan levere dokumentation ved hjælp af attributten beskrivelse skema.
|
Hvis du bruger Jackson som din JSON-parser, så gør du det for at tillade kommentarer:
ObjectMapper-kortlægger = ny ObjectMapper (). Konfigurer (Feature.ALLOW_COMMENTS, sand);
Så kan du have kommentarer som denne:
{
nøgle: "værdi" // Kommentar
}
Og du kan også have kommentarer startende med # ved at indstille:
mapper.configure (Feature.ALLOW_YAML_COMMENTS, sand);
Men generelt (som besvaret før) tillader specifikationen ikke kommentarer.
|
Her er hvad jeg fandt i Google Firebase-dokumentationen, der giver dig mulighed for at placere kommentarer i JSON:
{
"//": "Nogle browsere bruger dette til at aktivere push-underretninger.",
"//": "Det er det samme for alle projekter, dette er ikke dit projekts afsender-id",
"gcm_sender_id": "1234567890"
}
|
INGEN. JSON plejede at støtte kommentarer, men de blev misbrugt og fjernet fra standarden.
Fra skaberen af JSON:
Jeg fjernede kommentarer fra JSON, fordi jeg så, at folk brugte dem til at holde analysedirektiver, en praksis, der ville have ødelagt interoperabilitet. Jeg ved, at manglen på kommentarer gør nogle mennesker triste, men det burde det ikke. - Douglas Crockford, 2012
Det officielle JSON-websted findes på JSON.org. JSON er defineret som en standard af ECMA International. Der er altid en andragende for at få standarder revideret. Det er usandsynligt, at kommentarer vil blive tilføjet til JSON-standarden af flere grunde.
JSON by design er et let omvendt konstrueret (human parset) alternativ til XML. Det er forenklet, selv til det punkt, at kommentarer ikke er unødvendige. Det er ikke engang et markup-sprog. Målet er stabilitet og interoperabilitet.
Enhver, der forstår "has-a" -forholdet mellem objektorientering kan forstå enhver JSON-struktur - det er hele pointen. Det er bare en rettet acyklisk graf (DAG) med nodemærker (nøgle / værdipar), som er en næsten universel datastruktur.
Denne eneste krævede kommentar kan være "// Dette er DAG-tags". Nøglenavnene kan være så informative som krævet, hvilket tillader vilkårlig semantisk aritet.
Enhver platform kan analysere JSON med blot nogle få linjer kode. XML kræver komplekse OO-biblioteker, der ikke er levedygtige på mange platforme.
Kommentarer ville bare gøre JSON mindre interoperabel. Der er simpelthen intet andet at tilføje, medmindre det, du virkelig har brug for, er et markeringssprog (XML), og er ligeglad med, om dine vedvarende data let kan parses.
MEN som skaberen af JSON også bemærkede, har der altid været JS pipeline-support til kommentarer:
Gå videre og indsæt alle de kommentarer, du kan lide.
Rør det derefter gennem JSMin, inden du afleverer det til din JSON-parser. - Douglas Crockford, 2012
|
Hvis din tekstfil, som er en JSON-streng, skal læses af et eller andet program, hvor vanskeligt ville det være at fjerne enten C- eller C ++ -kommentarer, før du bruger den?
Svar: Det ville være en liner. Hvis du gør det, kan JSON-filer bruges som konfigurationsfiler.
|
Hvis du bruger Newtonsoft.Json-biblioteket med ASP.NET til at læse / deserialisere, kan du bruge kommentarer i JSON-indholdet:
// "navn": "streng"
// "id": int
eller
/* Dette er en
kommentareksempel * /
PS: Kommentarer med en linje understøttes kun med 6+ versioner af Newtonsoft Json.
Yderligere bemærkning til folk, der ikke kan tænke ud af boksen: Jeg bruger JSON-formatet til grundlæggende indstillinger i en ASP.NET-webapplikation, jeg lavede. Jeg læser filen, konverterer den til indstillingsobjektet med Newtonsoft-biblioteket og bruger den, når det er nødvendigt.
Jeg foretrækker at skrive kommentarer om hver enkelt indstilling i selve JSON-filen, og jeg er virkelig ligeglad med integriteten af JSON-formatet, så længe det bibliotek, jeg bruger, er OK med det.
Jeg synes, det er en 'lettere at bruge / forstå' måde end at oprette en separat 'settings.README' fil og forklare indstillingerne i den.
Hvis du har et problem med denne form for brug; undskyld, slægten er ude af lampen. Folk ville finde andre anvendelser tilJSON-format, og der er ikke noget, du kan gøre ved det.
|
Ideen bag JSON er at tilvejebringe enkel dataudveksling mellem applikationer. Disse er typisk webbaserede, og sproget er JavaScript.
Det tillader ikke rigtig kommentarer som sådan, men at sende en kommentar som et af navn / værdipar i dataene vil helt sikkert fungere, selvom disse data naturligvis skulle ignoreres eller håndteres specifikt af parsingskoden.
Alt det sagt er det ikke meningen, at JSON-filen skal indeholde kommentarer i traditionel forstand. Det skal bare være dataene.
Se JSON-webstedet for flere detaljer.
|
JSON understøtter ikke indbyggede kommentarer, men du kan lave din egen dekoder eller i det mindste forbehandling til at fjerne kommentarer, det er helt fint (så længe du bare ignorerer kommentarer og ikke bruger dem til at guide, hvordan din applikation skal behandle JSON-data ).
JSON har ingen kommentarer. En JSON-encoder MÅ IKKE sende kommentarer.
En JSON-dekoder KAN acceptere og ignorere kommentarer.
Kommentarer bør aldrig bruges til at overføre noget meningsfuldt. Det er
hvad JSON er til.
Jf: Douglas Crockford, forfatter til JSON spec.
|
Jeg støder lige på dette til konfigurationsfiler. Jeg vil ikke bruge XML (detaljeret, grafisk, grimt, svært at læse) eller "ini" -format (intet hierarki, ingen reel standard osv.) Eller Java "Properties" -format (som .ini).
JSON kan gøre alt, hvad de kan, men det er langt mindre detaljeret og mere menneskeligt læsbart - og parsers er lette og allestedsnærværende på mange sprog. Det er bare et datatræ. Men kommentarer uden for båndet er ofte en nødvendighed for at dokumentere "standard" -konfigurationer og lignende. Konfigurationer skal aldrig være "fulde dokumenter", men træer med gemte data, der kan læses af mennesker, når det er nødvendigt.
Jeg antager, at man kunne bruge "#": "kommentar" til "gyldig" JSON.
|
Det afhænger af dit JSON-bibliotek. Json.NET understøtter kommentarer i JavaScript-stil, / * kommission * /.
Se et andet Stack Overflow-spørgsmål.
|
JSON giver meget mening for konfigurationsfiler og anden lokal brug, fordi den er allestedsnærværende, og fordi den er meget enklere end XML.
Hvis folk har stærke grunde til at have kommentarer i JSON, når de kommunikerer data (uanset om de er gyldige eller ej), kan JSON muligvis opdeles i to:
JSON-COM: JSON på ledningen eller regler, der gælder ved kommunikation af JSON-data.
JSON-DOC: JSON-dokument eller JSON i filer eller lokalt. Regler, der definerer et gyldigt JSON-dokument.
JSON-DOC tillader kommentarer, og andre mindre forskelle kan eksistere, såsom håndtering af mellemrum. Parsere kan let konvertere fra en spec til den anden.
Med hensyn til bemærkning fra Douglas Crockford om disse spørgsmål (refereret af @Artur Czajka)
Antag at du bruger JSON til at beholde konfigurationsfiler, som du gerne vil kommentere. Gå videre og indsæt alle de kommentarer, du kan lide. Rør det derefter gennem JSMin, inden du afleverer det til din JSON-parser.
Vi taler om et generisk konfigurationsfilproblem (på tværs af sprog / platform), og han svarer med et JS-specifikt værktøj!
Sikker på, at en JSON-specifik minify kan implementeres på ethvert sprog,
men standardiser dette, så det bliver allestedsnærværende på tværs af parsere på alle sprog og platforme, så folk holder op med at spilde deres tid på at mangle funktionen, fordi de har gode brugssituationer til det, ser problemet op i onlinefora og får folk til at fortælle dem, at det er en dårlig idé eller foreslår, at det er let at implementere fjernelse af kommentarer fra tekstfiler.
Det andet spørgsmål er interoperabilitet. Antag, at du har et bibliotek eller API eller nogen form for subsystem, der har nogle konfigurations- eller datafiler tilknyttet. Og dette delsystem er
der skal tilgås fra forskellige sprog. Så går du rundt og fortæller folk: forresten
glem ikke at fjerne kommentarer fra JSON-filerne, før du sender dem til parseren!
|
Hvis du bruger JSON5, kan du medtage kommentarer.
JSON5 er en foreslået udvidelse til JSON, der har til formål at gøre det lettere for mennesker at skrive og vedligeholde i hånden. Det gør det ved at tilføje nogle minimale syntaksfunktioner direkte fra ECMAScript 5.
|
Dojo Toolkit JavaScript-værktøjssæt (i det mindste fra version 1.4) giver dig mulighed for at medtage kommentarer i din JSON. Kommentarerne kan være i / * * / format. Dojo Toolkit bruger JSON via dojo.xhrGet () opkaldet.
Andre JavaScript-værktøjssæt fungerer muligvis på samme måde.
Dette kan være nyttigt, når du eksperimenterer med alternative datastrukturer (eller endda datalister), før du vælger en endelig mulighed.
|
JSON er ikke en indrammet protokol. Det er et sprogfrit format. Så en kommentars format er ikke defineret for JSON.
Som mange mennesker har foreslået, er der nogle tricks, for eksempel duplikatnøgler eller en bestemt nøgle _kommentar, som du kan bruge. Det er op til dig.
|
Du kan have kommentarer i JSONP, men ikke i ren JSON. Jeg har lige brugt en time på at få mit program til at fungere med dette eksempel fra Highcharts: http://www.highcharts.com/samples/data/jsonp.php?filename=aapl-c.json&callback=?
Hvis du følger linket, vil du se
? (/ * AAPLhistoriske OHLC-data fra Google Finance API * /
[
/ * Maj 2006 * /
[1147651200000,67.79],
[1147737600000,64.98],
...
[1368057600000,456.77],
[1368144000000,452.97]
]);
Da jeg havde en lignende fil i min lokale mappe, var der ingen problemer med samme oprindelsespolitik, så jeg besluttede at bruge ren JSON ... og selvfølgelig mislykkedes $ .getJSON lydløst på grund af kommentarerne.
Til sidst sendte jeg bare en manuel HTTP-anmodning til adressen ovenfor og indså, at indholdstypen var tekst / javascript, da JSONP, ja, returnerer ren JavaScript. I dette tilfælde er kommentarer tilladt. Men min applikation returnerede indholdstypeapplikation / json, så jeg var nødt til at fjerne kommentarerne.
|
Dette er et "kan du" spørgsmål. Og her er et "ja" svar.
Nej, du skal ikke bruge duplikative objektmedlemmer til at indsætte sidekanaldata i en JSON-kodning. (Se "Navnene i et objekt SKAL være unikke" i RFC).
Og ja, du kan indsætte kommentarer omkring JSON, som du kan analysere.
Men hvis du vil have en måde at indsætte og udtrække vilkårlige sidekanaldata til en gyldig JSON, er her et svar. Vi drager fordel af den ikke-unikke repræsentation af data i en JSON-kodning. Dette er tilladt * i afsnit 2 i RFC under "mellemrum er tilladt før eller efter et af de seks strukturelle tegn".
* RFC angiver kun "hvidt mellemrum er tilladt før eller efter et af de seks strukturelle tegn" og nævner ikke eksplicit strenge, tal, "falsk", "sand" og "null". Denne udeladelse ignoreres i ALLE implementeringer.
Først kanoniserer du din JSON ved at formindske den:
$ jsonMin = json_encode (json_decode ($ json));
Kod derefter din kommentar i binær:
$ hex = pakke ud ('H *', $ kommentar);
$ commentBinary = base_convert ($ hex [1], 16, 2);
Steg derefter din binære:
$ steg = str_replace ('0', '', $ commentBinary);
$ steg = str_replace ('1', "\ t", $ steg);
Her er din output:
$ jsonWithComment = $ steg. $ jsonMin;
|
Ansvarsfraskrivelse: Dette er fjollet
Der er faktisk en måde at tilføje kommentarer på og holde sig inden for specifikationen (ingen yderligere parser nødvendig). Det vil dog ikke resultere i menneskelæsbare kommentarer uden nogen form for parsing.
Du kan misbruge følgende:
Ubetydelig hvidt mellemrum er tilladt før eller efter ethvert token.
Hvidrum er en hvilken som helst sekvens af en eller flere af følgende kode
point: tegnetabellering (U + 0009), linjefodring (U + 000A), vogn
return (U + 000D) og mellemrum (U + 0020).
På en hacky måde kan du misbruge dette for at tilføje en kommentar. For eksempel: start og afslut din kommentar med en fane. Kod kommentaren i base3, og brug de andre tegn i mellemrummet til at repræsentere dem. For eksempel.
010212 010202 011000 011000 011010 001012 010122 010121 011021 010202 001012 011022 010212 011020 010202 010202
(hej base tre i ASCII) Men i stedet for 0 brug plads, til 1 brug linjefoder og til 2 brug vognretur.
Dette vil bare efterlade dig med en masse ulæseligt mellemrum (medmindre du laver et IDE-plugin til at kode / afkode det i farten).
Jeg har aldrig engang prøvet dette af åbenlyse grunde, og det skal du heller ikke.
|
JSON tillader ikke kommentarer i sig selv. Ræsonnementet er fuldstændig dumt, fordi du kan bruge JSON selv til at oprette kommentarer, hvilket helt undgår ræsonnementet og indlæser parser-datarummet uden nogen god grund overhovedet til nøjagtigt det samme resultat og potentielle problemer, som de er: en JSON fil med kommentarer.
Hvis du prøver at placere kommentarer (f.eks. Ved hjælp af // eller / * * / eller #), vil nogle parsere mislykkes, fordi dette strengt taget ikke er
inden for JSON-specifikationen. Så du skal aldrig gøre det.
Her for eksempel, hvor mit billedmanipulationssystem har gemt billednotationer og nogle grundlæggende formaterede (kommentar) oplysninger om dem (nederst):
{
"Notationer": [
{
"anchorX": 333,
"ankerY": 265,
"areaMode": "Ellipse",
"measureX": 356,
"omfangY": 294,
"opacitet": 0,5,
"text": "Elliptisk område øverst",
"textX": 333,
"tekstY": 265,
"title": "Notation 1"
},
{
"anchorX": 87,
"ankerY": 385,
"areaMode": "Rektangel",
"measureX": 109,
"omfangY": 412,
"opacitet": 0,5,
"text": "Rect area \ non bottom",
"textX": 98,
"tekstY": 385,
"title": "Notation 2"
},
{
"anchorX": 69,
"ankerY": 104,
"areaMode": "Polygon",
"omfangX": 102,
"omfangY": 136,
"opacitet": 0,5,
"pointList": [
{
"i": 0,
"x": 83,
"y": 104
},
{
"i": 1,
"x": 69,
"y": 136
},
{
"i": 2,
"x": 102,
"y": 132
},
{
"jeg": 3,
"x": 83,
"y": 104
}
],
"text": "Enkel polygon",
"textX": 85,
"tekstY": 104,
"title": "Notation 3"
}
],
"imageXW": 512,
"imageYW": 512,
"imageName": "lena_std.ato",
"tinyDocs": {
"c01": "JSON-billednotationsdata:",
"c02": "-------------------------",
"c03": "",
"c04": "Disse data indeholder billednotationer og beslægtet område",
"c05": "valginformation, der giver et middel til en",
"c06": "billedgalleri til visning af notationer med elliptisk,",
"c07": "indikationer på rektangulære, polygonale eller frihåndsområder",
"c08": "over et billede, der vises til en galleribesøg.",
"c09": "",
"c10": "X- og Y-positioner er alle i billedetplads. Billedet",
"c11": "opløsning gives som imageXW og imageYW, hvilket",
"c12": "du bruger til at skalere notationsområderne til deres rette",
"c13": "placeringer og størrelser til din visning af billedet,",
"c14": "uanset skala.",
"c15": "",
"c16": "For ellipser er anker centrum for ellipsen,",
"c17": "og omfanget er henholdsvis X- og Y-radierne.",
"c18": "",
"c19": "For rektangler er ankeret øverst til venstre og",
"c20": "extents er nederst til højre.",
"c21": "",
"c22": "For frihånds- og polygon-områdetilstande, pointList",
"c23": "indeholder en række nummererede XY-punkter. Hvis området",
"c24": "er lukket, det sidste punkt vil være det samme som",
"c25": "først, så alt hvad du skal bekymre dig om er at tegne",
"c26": "linjer mellem punkterne i listen. Anker og omfang",
"c27": "er indstillet øverst til venstre og nederst til højre for det angivne",
"c28": "region, og kan bruges som en forenklet rektangulær",
"c29": "detekter for musens holdeposition over disse typer",
"c30": "af områder.",
"c31": "",
"c32": "Positionerne textx og texty giver grundlæggende positionering",
"c33": "information for at hjælpe dig med at finde tekstoplysningerne",
"c34": "et rimeligt sted forbundet med området",
"c35": "indikation.",
"c36": "",
"c37": "Opacitet er en værdi mellem 0 og 1, hvor .5 repræsenterer",
"c38": "en 50% uigennemsigtig baggrund og 1,0 repræsenterer en fuldstændig uigennemsigtig",
"c39": "baggrund. Anbefaling er, at regioner tegnes",
"c40": "kun hvis brugeren svæver markøren over billedet,",
"c41": "og at teksten tilknyttet regionerne tegnes",
"c42": "kun hvis brugeren svæver markøren over det angivne",
"c43": "region."
}
}
|
Vi bruger strip-json-kommentarer til vores projekt. Det understøtter noget som:
/ *
* Beskrivelse
* /
{
// regnbuer
"enhjørning": / * ❤ * / "kage"
}
Simpelthen npm install - gem strip-json-comments for at installere og bruge det som:
var strip_json_comments = kræver ('strip-json-kommentarer')
var json = '{/ * regnbuer * / "enhjørning": "kage"}';
JSON.parse (strip_json_comments (json));
// => {enhjørning: 'kage'}
|
I mit tilfælde skal jeg bruge kommentarer til fejlretningsformål lige før output af JSON-strukturen. Så jeg besluttede at bruge fejlretningsoplysninger i HTTP-overskriften for at undgå at bryde klienten:
header ("My-Json-Comment: Ja, jeg ved, det er en løsning ;-)");
|
For at skære et JSON-emne i dele tilføjer jeg "dummy comment" -linjer:
{
"#############################" : "Del 1",
"data1": "værdi1",
"data2": "værdi2",
"#############################" : "Del 2",
"data4": "værdi3",
"data3": "værdi4"
}
|
1
2
Næste
Meget aktivt spørgsmål. Optjen 10 omdømme for at besvare dette spørgsmål. Omdømmekravet hjælper med at beskytte dette spørgsmål mod spam og ikke-svar-aktivitet.
Er det ikke det svar, du leder efter? Gennemse andre spørgsmål med mærkede json-kommentarer, eller stil dit eget spørgsmål.